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Abstract 

The  Navy  has  designated  the  Naval  Research  Labora¬ 
tory  (NRL)  as  its  Center  for  Computer  Security  Re¬ 
search  and  Evaluation.  NRL  is  actively  developing 
a  Navy  capability  to  certify  trusted  systems.  This 
paper  describes  the  NRL  effort  to  understand  assur¬ 
ance,  certihcation,  and  trusted  system  certihcation  cri¬ 
teria  through  the  production  of  the  Handbook  for  the 
Computer  Security  Certihcation  of  Trusted  Systems. 
Through  this  effort,  NRL  hopes  to  discover  new  and 
more  efhcient  ways  of  satisfying  the  assurance  require¬ 
ment  for  a  high  assurance  system. 

1  Introduction 

In  the  past  few  years,  DoD  policy  makers  have  begun 
to  view  computer  security  as  an  enabling  technology, 
which  will  allow  the  Services  to  share  classihed  infor¬ 
mation  securely  and  legitimately.  Several  factors  mo¬ 
tivated  this  change  in  policy.  The  computer  security 
community,  primarily  through  the  leadership  of  the  Na¬ 
tional  Computer  Security  Center,  convinced  industry 
that  there  is  a  real  need  for  computer  security  prod¬ 
ucts.  Industry  responded  with  the  development  of  new 
products  that  are  beginning  to  populate  the  Evalu¬ 
ated  Products  List  (EPL),  especially  at  the  lower  trust 
classes  of  the  Trusted  Computer  System  Evaluation 
Criteria  (TCSEC)  [1].  Widely  publicized  penetrations 
of  Government  computers  also  encouraged  widespread 
interest  in  computer  security.  The  computer  security 
community  is  challenged  to  produce  systems  that  pro- 
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tect  classihed  information,  that  satisfy  critical  require¬ 
ments,  and  that  provide  assurance  to  their  users  that 
they  are  trustworthy. 

The  development  of  a  software  engineering  method¬ 
ology  for  trusted  systems  has  been  a  major  research 
goal  at  NRL  for  several  years.  The  objective  of  this 
project  is  to  dehne  a  system  development  process  whose 
enactment  provides  assurance  that  the  computer  sys¬ 
tem  satishes  its  critical,  security  requirements.  Given 
such  a  trusted  development  process,  certihcation  that 
the  requirements  are  satished  becomes  a  technical  au¬ 
dit  of  the  development  process.  A  requirement  for  this 
endeavor  is  a  thorough  understanding  of  the  assurance 
required  for  certihcation. 

The  TCSEC  is  the  primary  security  certihcation  cri¬ 
teria  for  the  US.  To  better  understand  the  assurance 
required  by  the  TCSEC,  NRL  is  developing  a  com¬ 
puter  security  certihcation  handbook  for  trusted  sys¬ 
tems.  The  focus  of  this  project  is  the  B3  class  of  the 
TCSEC  primarily  because  our  objective  is  to  investi¬ 
gate  the  different  kinds  of  assurance  provided  by  differ¬ 
ent  development  strategies,  which  include  both  rigor¬ 
ous  design  and  engineering  approaches  as  well  as  formal 
methods.  This  handbook  will  serve  other  purposes  as 
well.  NRL’s  goals  are  to  develop  a  Navy  capability 
to  certify  trusted  systems,  to  document  an  evaluation 
methodology  and  train  Navy  evaluators,  and  to  comply 
with  SECNAVINST  5239.2,  which  designates  NRL  as 
the  Navy  Center  for  Computer  Security  Research  and 
Evaluation.  This  short  paper  describes  the  NRL  effort 
to  understand  assurance,  certihcation,  and  trusted  sys¬ 
tem  certihcation  criteria  through  the  production  of  a 
Handbook  for  the  Computer  Security  Certihcation  of 
Trusted  Systems. 
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2  The  Trusted  System 

The  term,  trusted  system,  has  a  specihc  meaning  in 
the  Handbook.  NRL  has  adopted  the  dehnitions  of 
produet  and  system  as  stated  in  the  European  com¬ 
munity’s  Information  Technology  Security  Evaluation 
Criteria  (ITSEC)  [2].  According  to  the  ITSEC,  a  sys¬ 
tem  is  a  specihc  installation  “with  a  particular  purpose 
and  a  known  operational  environment”.  A  produet,  on 
the  other  hand,  is  “a  hardware  and/or  software  pack¬ 
age  that  can  be  bought  off  the  shelf  and  incorporated 
into  a  variety  of  systems” .  This  distinction  between  a 
product  and  a  system  is  only  implicit  in  the  TCSEC.  A 
trusted  system,  then,  is  a  system  that  has  been  certihed 
against  some  trust  criteria. 

The  characteristics  and  requirements  of  a  trusted 
system’s  end-users  are  well  known,  and  threats  to  a 
trusted  system’s  security  can  be  determined  with  some 
certainty.  The  security  requirements  that  it  must  en¬ 
force  are  unique  interpretations  of  a  national  security 
policy.  If  the  trusted  system  is  based  on  a  trusted  prod¬ 
uct,  the  person  deploying  the  trusted  system  must  en¬ 
sure  that  the  assumptions  of  the  trusted  product  are 
valid  for  the  operating  environment.  It  may  be  nec¬ 
essary  to  develop  additional  trusted  code  to  enforce 
environment-specihc  security  requirements. 

The  ITSEC  notes  that  for  the  sake  of  consistency,  the 
same  trust  criteria  should  be  applied  to  both  trusted 
systems  and  trusted  products.  The  TCSEC,  on  the 
other  hand,  asserts  that  while  its  assurance  require¬ 
ments  can  be  applied  “to  the  full  range  of  comput¬ 
ing  environments”  ,  its  security  feature  requirements  are 
targetted  primarily  at  “information  processing  systems 
employing  general-purpose  operating  systems  that  are 
distinct  from  the  application  programs  being  sup¬ 
ported”,  i.e.,  trusted  products.  NRL  assumes  that  the 
TCSEC  can  be  extended  to  trusted  systems.  The  certi- 
Rcation  evidence  that  is  assessed  for  a  trusted  product 
must  be  assessed  for  a  trusted  system  also. 

3  Computer  Security 
Certification 

Certification  contributes  significantly  to  the  demon¬ 
stration  that  a  system  is  trustworthy.  Certification 
supports  the  accreditation  decision  to  allow  the  sys¬ 
tem  to  process  classified  information  in  an  operational 
environment.  Trusted  system  certification^  comprises 
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several  technical  and  procedural  certifications,  includ¬ 
ing  a  technical  computer  security  certification  of  the 
system’s  security  features.  Computer  security  certifica¬ 
tion  is  the  independent  technical  evaluation  of  a  trusted 
system  to  determine  whether  the  system  satisfies  a  set 
of  critical  operational  and  assurance  requirements,  e.g., 
the  TCSEC.  The  outcome  of  the  computer  security  cer¬ 
tification  influences  the  criteria  for  other  system  certifi¬ 
cations,  such  as  administrative  and  personnel  security. 
If  the  protection  features  of  the  computer  system  are 
deficient  in  any  way,  other  protection  measures  must 
be  employed  to  protect  the  information  and  processes 
controlled  by  the  system. 

The  computer  security  certification  of  a  trusted  prod¬ 
uct  and  the  computer  security  certification  of  a  trusted 
system  may  be  based  on  the  same  criteria,  but  the  ef¬ 
fort  involved  is  significantly  different.  Trusted  product 
evaluations  can  take  three  to  four  years.  The  vendor 
accepts  this  rigorous  process  because  he  knows  that 
his  product  can  be  sold  to  many  different  customers. 
Trusted  systems  are  for  a  single  customer.  The  cus¬ 
tomer  usually  cannot  tolerate  a  long  delay  in  the  de¬ 
livery  and/or  operational  use  of  the  trusted  system. 
Alternate  certification  approaches  must  be  explored  to 
reduce  this  delay. 

One  possible  approach,  which  is  similar  to  the 
trusted  product  evaluation  process,  is  to  provide  se¬ 
curity  engineering  expertise  to  the  program  manager 
and  to  the  developer  during  system  construction  and 
then  to  assign  an  evaluation  team  to  assess  the  com¬ 
pleted  system.  The  security  engineering  support  team 
must  be  different  from  the  evaluation  team  in  order  to 
preserve  the  independence  of  the  evaluation.  Although 
this  approach  is  straightforward  and  a  delivered  sys¬ 
tem  is  likely,  it  does  not  allow  opportunity  to  change 
course  or  correct  mistakes  during  development.  The 
delivered  system  may  not  be  certified  at  the  required 
TCSEC  class  and  may  require  redevelopment  to  sat¬ 
isfy  its  security  requirements.  In  general,  performing  a 
technical  evaluation  after  the  system  is  completed  can 
significantly  delay  operational  use  of  the  system. 

Another  approach  is  to  structure  the  certification  as 
an  independent  security  verification  and  validation  pro¬ 
cess.  Since  the  TCSEC  describes  evidence  for  a  com¬ 
pleted  trusted  product,  the  challenge  is  to  determine 
what  certification  evidence  is  needed  at  each  milestone 
of  the  development  process  in  order  to  determine  that 
the  resulting  system  can  be  certified.  Certihability  is 
defined  as  the  contractual  acceptance  of  the  certifica¬ 
tion  evidence  for  a  particular  milestone,  and  it  is  as¬ 
sessed  at  each  milestone.  This  approach  is  success  ori- 


ented:  if  a  system  is  delivered,  it  can  be  certified.  Un¬ 
fortunately,  the  system  may  never  be  delivered,  partic¬ 
ularly  if  the  system  requirements  are  not  well  under¬ 
stood.  This  approach  can  also  lengthen  the  develop¬ 
ment  time  signihcantly  and  threaten  the  independence 
of  the  evaluation  team. 

Our  goal  is  to  dehne  a  trusted  system  development 
process  that  employs  the  assurance  criteria  required  for 
certihcation  to  support  development.  The  development 
environment  would  be  based  on  a  dehnition  of  trusted 
conhguration  management.  Only  authorized  members 
of  the  development  team  could  make  changes  to  doc¬ 
umentation  and  code;  only  authorized  members  of  the 
certihcation  team  could  generate  certihcation  assess¬ 
ments  of  certain  evidence.  Most  of  the  certihcation 
process  would  evolve  into  an  audit  of  the  assurance 
processes  performed  during  the  trusted  system’s  devel¬ 
opment.  Throughout  the  development  lifecycle,  certi- 
hability  would  be  continuously  assessed  and  ensured. 
The  delivered  trusted  system  would  be  certihable  at 
the  target  class  and  the  independence  of  the  evaluation 
would  be  preserved.  The  trusted  development  environ¬ 
ment  would  remain  available  to  the  system  maintainers 
and  would  ensure  that  the  only  changes  permitted  to 
the  system  are  those  that  result  in  a  certihable  system. 

Since  the  dehnition  of  this  trusted  system  develop¬ 
ment  process  relies  heavily  on  an  understanding  of  as¬ 
surance  and  the  contributions  of  the  TCSEC  certih¬ 
cation  evidence  thereof,  the  next  section  explores  the 
meaning  of  assurance  and  identihes  some  of  the  special 
issues  that  must  be  considered  for  trusted  systems. 

4  Assurance  for  Trusted 
Systems 

Assurance  is  the  conhdence  gained  from  compelling  ev¬ 
idence  that  a  system  satishes  its  critical  requirements. 
Assurance  about  critical  system  behavior  results  from 
many  factors,  including  the  unambiguous  specihcation 
of  critical  requirements,  formal  specihcation  and  proof 
techniques,  visibility  into  the  system  design  and  de¬ 
velopment  process,  well  structured  software  architec¬ 
tures,  rigorous  schemes  for  demonstrating  correspon¬ 
dence  between  a  system  and  its  requirements,  indepen¬ 
dence  among  the  software  building  blocks,  understand¬ 
able  documentation,  testing,  independent  evaluation, 
and  the  credentials  of  the  system  developers  and  evalu¬ 
ators.  All  of  these  activities  contribute  to  the  assurance 
argument  for  a  trusted  system;  no  single  activity  pro¬ 
vides  evidence  that  convinces  users  conclusively  that 


the  system  behaves  as  expected  in  the  context  of  its 
critical  requirements. 

The  previous  section  noted  that  while  certihcations 
for  trusted  products  and  trusted  systems  may  be  based 
on  the  same  criteria,  the  effort  involved  is  very  differ¬ 
ent.  The  difference  is  borne  from  the  assurance  ar¬ 
gument  that  must  be  constructed  to  support  the  cer¬ 
tihcation.  The  trusted  system’s  assurance  argument 
consumes  greater  development  resources  than  a  trusted 
product’s  because  the  trusted  system’s  security  policy 
is  more  comprehensive  than  the  trusted  product’s.  For 
example,  the  trusted  system’s  security  policy  may  name 
individual  users  and  identify  unique  relationships  be¬ 
tween  them.  The  same  is  true  of  the  objects  that  must 
be  protected  by  the  system.  In  addition,  the  trusted 
system  must  enforce  unique  interpretations  of  a  secu¬ 
rity  policy.  All  of  this  means  that  the  assurance  argu¬ 
ment  for  a  trusted  system  can  be  very  complex. 

The  complexity  of  a  trusted  system’s  assurance  argu¬ 
ment  affects  the  content  of  the  certihcation  evidence. 
For  example,  a  trusted  product  enforces  a  relatively 
simple,  well-understood  security  policy,  so  its  formal 
model  of  the  security  policy  (FMSP)  rehects  this  sim¬ 
plicity.  However,  the  security  policy  for  a  trusted  sys¬ 
tem,  as  argued  above,  is  much  more  comprehensive. 
The  dehnition  of  security  that  a  trusted  system  must 
enforce  may  not  be  well-understood  by  the  user  or  the 
developer.  The  trusted  system’s  FMSP,  then,  must 
provide  this  dehnition  in  a  clear  and  concise  exposition. 
Certain  pieces  of  evidence,  such  as  the  FMSP,  play  a 
more  critical  role  in  the  development  of  a  trusted  sys¬ 
tem  than  they  do  in  a  trusted  product,  because  they 
help  clarify  the  design  and  implementation  goals  for  the 
trusted  system’s  development. 

5  The  Handbook 

The  Handbook  targets  a  diverse  audience,  including  ac¬ 
quisition  managers,  program  managers,  evaluators  and 
users.  This  effort  is  based  not  only  on  NRL’s  experience 
in  computer  security  evaluation  but  on  its  experience 
and  research  in  software  engineering,  formal  methods 
and  computer  security. 

The  Handbook  will  examine  each  piece  of  certihca¬ 
tion  evidence  required  by  the  TCSEC  for  the  assur¬ 
ance  that  it  can  provide  during  the  development  of  a 
trusted  system.  The  primary  reader  of  this  handbook 
(a  trusted  system  evaluator)  should  gain  signihcant  in¬ 
sights  into  the  contribution  of  each  piece  of  evidence  to 
the  assurance  argument.  NHL  has  chosen  the  B3  class 


for  study  because  we  want  to  investigate  the  different 
kinds  of  assurance  provided  by  different  development 
strategies,  and  this  class  includes  rigorous  design  and 
engineering  approaches  as  well  as  formal  methods. 

A  B3  TCB  is  a  painstakingly  crafted,  tightly  en¬ 
gineered  set  of  software  and  hardware.  However,  as 
discussed  above,  engineering  the  TCB  constitutes  only 
part  of  the  effort  —  the  assurance  argument  consumes 
a  signihcant  portion  of  the  development  resources.  To 
illustrate  the  importance  of  this  argument  for  high  as¬ 
surance  systems,  the  primary  difference  between  the  B3 
class  and  the  A1  class  is  the  presentation  of  the  assur¬ 
ance  argument.  For  example,  the  B3  class  requires  only 
an  informal  specihcation  of  the  TCB  interface  and  an 
informal  argument  that  this  interface  satisRes  the  re¬ 
quirements  of  the  FMSP.  At  the  A1  class,  both  the 
specification  and  its  corresponding  argument  must  be 
expressed  formally.  As  one  advances  from  the  lowest 
class  through  the  higher  classes  of  the  TCSEC,  the  as¬ 
surance  argument  becomes  more  important  to  the  cer¬ 
tification  effort. 

The  Handbook  consists  of  a  chapter  for  each  piece 
of  certification  evidence,  as  well  as  an  overview  chapter 
with  a  sample  plan  for  certifying  a  B3  trusted  system. 
There  is  also  a  separate  chapter  for  the  trusted  system 
development  plan.  The  certification  evidence  for  a  B3 
TCB  includes: 

•  existence  and  documentation  of  a  configuration 
management  system 

•  a  Formal  Model  of  the  Security  Policy  (FMSP) 

•  a  Descriptive  Top  Level  Specification  (DTPS)  of 
the  TCB’s  interface 

•  a  detailed  design 

•  a  demonstration  that  the  DTPS  is  consistent  with 
the  FMSP 

•  an  implementation  (source  code  and  related  docu¬ 
ments) 

•  a  demonstration  that  the  implementation  is  con¬ 
sistent  with  the  DTPS 

•  a  covert  channel  analysis 

•  security  features  testing 

•  penetration  testing 

•  a  Security  Features  User’s  Guide 


•  a  Trusted  Facility  Manual 

Each  chapter  provides  an  overview  for  the  program 
manager,  a  precise  description  of  the  evidence  and  its 
purposes,  and  a  detailed  tutorial  for  evaluating  the  ev¬ 
idence.  There  are  several  questions  that  each  chap¬ 
ter  must  address.  Those  questions  (as  applied  to  the 
FMSP)  are  below: 

•  Whai  IS  an  FMSP?  The  composition  and  struc¬ 
ture  of  the  FMSP  are  described  along  with  its  pri¬ 
mary  purpose  and  use.  This  question  is  actually 
answered  twice  —  a  broad  view  of  the  FMSP  is 
provided  for  the  program  manager  as  part  of  the 
planning  guidance,  and  then  a  specific  description 
is  provided  for  the  evaluator.  For  example,  the 
latter  discussion  includes: 

—  what  is  meant  by  “formal” , 

—  the  role  of  the  computational  model  and  some 
examples, 

—  the  role  of  the  definition  of  security  and  how  it 
can  be  expressed  in  the  computational  models 
discussed  previously, 

—  the  role  of  assumptions  in  an  FMSP,  and  fi¬ 
nally, 

—  the  FMSP’s  contribution  to  the  assurance  ar¬ 
gument,  including  its  correspondence  to  the 
trusted  system  security  policy  and  how  it  fa¬ 
cilitates  the  development  of  future  evidence 
(e.g.,  the  DTPS)  through  the  construction  of 
a  concrete  model. 

•  Whai  IS  its  purpose,  and  whai  makes  a  good  one? 
At  least  three  parties  examine  the  FMSP  during 
the  development  process:  the  developer,  the  user 
and  the  evaluator.  Each  party  uses  the  FMSP  for 
different  purposes.  Each  purpose  is  identified,  and 
the  qualities  of  the  FMSP  that  fulfill  that  purpose 
are  discussed. 

•  Flow  does  ihe  FMSP  fii  mio  ihe  developmeni  life 
eyele?  No  piece  of  evidence  is  meant  to  be  pro¬ 
duced  and  put  on  a  shelf.  Its  impact  on  the  subse¬ 
quent  system  development  as  well  as  other  certifi¬ 
cation  evidence  must  be  explored.  The  FMSP,  for 
example,  states  the  formal  definition  of  security  for 
the  trusted  system,  and  this  definition  should  be 
interpreted  for  each  stage  of  the  trusted  system’s 
design. 


•  Whai  information  is  used  to  develop  the  FMSP? 
Similarly,  the  impact  of  earlier  system  develop¬ 
ment  activities  and  certification  evidence  on  the 
development  of  the  FMSP  is  discussed. 

•  How  do  you  evaluate  the  FMSP?  The  bulk  of  what 
the  evaluator  should  understand  about  the  evi¬ 
dence  has  been  presented  already.  This  discussion 
concentrates  on  tactics  and  strategies  for  discover¬ 
ing  whether  the  evidence  satisRes  its  requirements 
and  fulfills  its  purposes. 

•  What  overall  assuranee  does  the  FMSP  provide? 
What  assuranee  does  the  FMSP  provide  before  the 
system  is  built?  These  questions  are  addressed 
throughout  the  chapter. 

Each  chapter  also  includes  a  sample  assessment  based 
on  the  discussion  therein. 

The  Handbook  addresses  some  of  the  fundamental 
issues  of  assurance,  so  it  is  not  an  evaluation  checklist. 
The  evaluator  should  not  expect  to  find  a  list  of  tasks  to 
perform  when  assessing  a  piece  of  certification  evidence, 
but  he  or  she  should  expect  to  find  the  answers  to 
questions  that  might  arise  during  the  evaluation.  Each 
trusted  system  is  unique,  so  each  trusted  system  evalua¬ 
tion  is  unique  as  well.  An  evaluation  checklist  is  insuffi¬ 
cient  for  all  circumstances,  because  the  trusted  system’s 
operational  environment  determines,  to  a  large  degree, 
what  assurance  must  be  provided. 

Writing  a  handbook  that  addresses  all  possible  eval¬ 
uation  and  security  policy  scenarios  is  impractical.  In¬ 
stead,  NRL  tries  to  identify  the  primary  contribution 
of  each  piece  of  certification  evidence  to  the  trusted 
system’s  assurance  argument.  It  is  likely  that  the  eval¬ 
uator  will  have  to  continue  researching  elsewhere  when 
evaluating  some  evidence,  but  we  hope  that  the  infor¬ 
mation  in  this  handbook  will  suggest  the  questions  that 
motivate  that  search. 
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6  Summary 

An  assurance  argument  is  a  critical  part  of  a  trusted 
system  certification,  particularly  for  those  systems  eval¬ 
uated  at  the  higher  levels  of  the  TCSEC.  NRL  hopes 
that  its  study  of  the  TCSEC ’s  certification  evidence 
will  yield  a  better  understanding  of  assurance  and  in 
turn,  a  better  approach  for  achieving  it. 


